Overview

What is Milwaukee Tool States Language?

Milwaukee Tool States Language (MTSL) is a JSON-based language used to describe state machines declaratively. State machines drive the functionality of the software dynamically. Typically, these state machines will involve performing some interaction with a compatible Milwaukee Tool product. The state machines thus defined may be executed by software. In this document, the software is referred to as "the interpreter".

Big Idea

MTSL defines a standard for dynamically driving functionality within any Milwaukee Tool software program

The JEDI team will build the first MTSL interpreter into QuickLink Web. However, other software clients could also consume these state machine objects and implement their own interpreter (e.g. - QuickLink Mobile, ToolSmith / Other LabView Applications).

The structure of Milwaukee Tool States Language and the concepts described within this document are originally based on the open source Amazon's States Language (ASL). ASL is the starting point from which we will morph and expand.

Motivation

There are many software programs around the company that connect to and interact with our products. To name just a few: QuickLink Web, QuickLink Mobile, Tool Smith, MX Restore, PC Test App, OneKey Mobile, mOneKey, etc.

Each of these software programs were built to solve unique problems. However, each must perform similar tasks (i.e. – connect to a product and sending OpenLink Commands). If there is desire for a program to drive functionally dynamically or save off a set of commands to run again later, each team must model this and stand up supporting infrastructure. Ultimately, this means that there is little interoperability between these programs and duplicate effort across systems. The desire with MTSL is to change this.

History

In 2021, the JEDI team built a JSON-based, declarative solution for dynamically driving functionality within QuickLink Web for our Service Technicians. We called it "OpenLinkActions". It worked great for the needs of our Service Hubs. It gave us confidence that a JSON-based, declarative solution for dynamically driving functionality was feasible.

Milwaukee Tool States Language aims to expand on the ideas of OpenLinkActions, apply learnings from the OpenLinkActions implementation, and lay a foundation for the future.

Why not call this a new version of OpenLinkActions? Milwaukee Tool States Language (MTSL) aims to be a long-term, highly extensible standard. In the future, perhaps we'll need to send CANOpen commands, BGAPI commands, or move away from the OpenLink Protocol entirely. MTSL will not be tied to any one communication protocol, nor any subset of possible tasks.

MTSL also offers greater control flow through the use of Choice and Map States which is something OpenLinkActions did not support.

What does that mean? MTSL allows us to describe things that should happen (connect to a tool, send a command, display some value) and then give that standardized description to any compliant MTSL interpreter software program to make those things happen.

Design Goals

• Extensibility
  • We never know what will be required in the future. Protocol changes, new hardware, and new business desires are always possibilities. The goal should always be to put in place a structure that is extensible and resilient to the unknown. When change inevitably occurs, this specification must be able to grow and change with it.
  • Must be able to drive functionality needed for Service Techs, Order Entry Clerks, Manufacturing Lines, Rework Lines, Electrical Engineers, and Software Engineers.
• Decoupled
  • Implementation details about the Web API, Database, and QuickLink Web Interpreter must be hidden.
  • The public facing API should be independent of the database choice. It should be possible to completely change the backing store without modifying the Web API.
  • The structure of these state machines should not assume that QuickLink Web will be the interpreter.
• Documented
  • Understandable to and extensively documented for users outside of JEDI

Who is this documentation for?

• Software, Electrical, and Reliability Engineers
• Anyone who may be defining state machines / scripts
• Anyone who may be building a MTSL interpreter